Subject: Re: Your reply to my suggestion/proposal...

From: [email-masked] (Scott Adams)
Date: Mon, 16 Aug 1993 15:23:44 -0400 (EDT)

Choon Lee,

from Scott Adams.

Thanks for your feedback...  I'm beginning to wonder, though, if
anyone else is out there...

> >> 
> >> 
> >> The other scenario I've thought about is where two or more DLSw's are
> >> connected to the same LAN or bridged LAN:
> >> 
> >>                      +-------+              +-------+
> >>                      |  S 1  |              |  S 2  |
> >>                      +---+---+              +---+---+
> >>                          |                      |
> >>              N1 -------+-+----     N2  -------+-+----
> >>                        |                      |
> >>                 +------+-------+      +-------+------+
> >>                 |   DLSw A     |      |   DLSw B     |
> >>                 +---+---+---+--+      +---+---+---+--+
> >>                    /|\ /|\ /|\           /|\ /|\ /|\
> >>                     |   |   +-------------+   |   |
> >>                     |   +-------+ +-----------+   |
> >>                     |            X              +-+
> >>                     |   +-------+ +---------+   |
> >>             |      \|/ \|/                 \|/ \|/        |
> >>             |     +-+---+--+             +--+---+-+       |
> >> +-----+     +-----+ DLSw C |             | DLSw D +-------+   +-----+
> >> | S 3 +-----+     +--------+             +--------+       +---+ S 4 |
> >> +-----+     |                                             |   +-----+
> >>             |                                             |
> >>             |     +--------+             +--------+       |
> >>             +-----+ Brdg A +<----------->+ Brdg B +-------+
> >>             |     +--------+             +--------+       |
> >>             |                                             |
> >>            N3                                            N3'
> >> 
> >> 
> >> Note that DLSw's C and D are not configured as partners.  This must be
> >> maintained because otherwise a parallel path (and loops) exist between
> >> networks N3 and N3'.  I suspect that this may be part of what the
> >> authors of RFC 1434 were trying to say in the last paragraph of
> >> section 3. Transport Connection.
> 
> My concern here is that a user may not realize the N3 and N3' are bridged, and 
> connect C and D as DLSw partners (N3 and N3' may be connected by a series 
> of brouters). This would constitute a "misconfiguration", but shouldn't that
> be detected and prevented ?
> 

I think the mechanism I suggested at the end of my last message
effectively deals with this problem.  Both DLSwitches would broadcast
a TWIK frame, which the other should receive and detect that they are
both connected to the same net, and to the same partners.  Each would
then select an exclusive group of partners out of the intersection of
their partners, and would thereafter not pass traffic or establish
Data Links with DLSw outside of their group.

> >> 
> >> What do people think of defining a "simple" protocol whereby each DLSw
> >> periodically announces that it exists on each LAN it is connected to,
> >> and who its DLSw partners are (call this a "This-is-Who-I-Know, or
> >> TWIK packet).  If a DLSw receives one of these packets it compares the
> >> other DLSw's partners to its own set of partners.  Using some
> >> yet-to-be-defined algorithm it selects a non-intersecting set of
> >> partners from the union of its partners and those reported by other
> >> DLSwitches on the same LAN.  Those selected partners it alone will
> >> communicate with.  The other DLSwitch(es) perform the same process,
> >> selecting their own non-intersecting set of partners.  Each DLSw flags
> >> as not useable the DLSw-DLSw connections it has to any partner not in
> >> its list.  When it receives a broadcast LAN frame that's to be
> >> propogated to DLSw partners, it doesn't send it out to those marked as
> >> unuseable.  Likewise, if it receives from a "marked" partner an SSP
> >> packet that would normally be broadcast to its local LAN(s), it would
> >> not do so.
> >> 
> In the case of parallel DLSw (in diagram above, imagine LANs N1 and N2 are
> bridged, DLSw A connected only to C, and B connected only to D), C thinks that 
> A is its only partner and D thinks that B is its only partner. How do they
> figure out that there's a loop?
> 

Good question.  In that situation my suggested solution doesn't cut
it.  But there is a way that it can be extended to fix the problem,
though.  TWIK frames broadcast on the LAN's contain the full IP
address of partner DLSw (DLSw A send a TWIK containting C's IP Addr, B
sends a TWIK with D's IP Addr, C send a TWIK w/ A's Addr and D send a
TWIK with B`s addr).  If receiving DLSw not only compare these partner
IP Addrs with their own partners, but also compare the IP Network
portion of these addrs (add the partner's subnet mask to the TWIK
packet, in addition to the IP addr), then each could detect that
another DLSw on the LAN has a partner on the same net as one of his
partners.  Then apply the same exclusion principle, but extended
slightly; ie: that only the DLSw with the lowest IP address can talk
with a partner DLSw on a given network.  In the new scenario you
describe, A and B would recognize that even though they don't share a
partner the partners they have are on the same network.  In that case
the DLSw with the lowest IP address would include its partner in its
partner group (say A has the lowest addr, then it would put C's addr
in its group).  B, recognizing that its partner is on the same net as
A's partner, and that its IP address is larger than A's, would not
include D in its partner goup (in fact, its group would be empty, thus
it wouldn't be able to talk to anyone).

> >> These DLSw partner sets would be updated, and aged, as a result of the
> >> periodic broadcasts from DLSw.  If a DLSw stops broadcasting, then the
> >> other DLSws, if connected with the same DLSw partners, would include
> >> those partners that had been "owned" by the failed DLSw.  This might
> >> take some time (if the TWIK period is 30 seconds, and the DLSws update
> >> their partner sets each period, then it would require 30 seconds to
> >> recover from a lost DLSw).
> >> 
> >> A simple algorithm for selecting the exclusive sets of partners is:
> >> Each DLSw chooses those partners only it knows about.  All partners in
> >> common with other DLSw are divided up evenly among the number of
> >> DLSw's that know about them, with the fractions assigned to DLSw in
> >> order of their IP addr host numbers.  For example, if there are 45
> >> DLSw partners known by four different DLSw on the same LAN, then the
> >> DLSw with the lowest host number would get the first twelve in the set
> >> (the set of partners is ordered by IP address taken as an unsigned 32
> >> bit number), the DLSw with the next lowest host number would get the
> >> next 11, and so on.
> >> 
> >> I suggest this because it doesn't seem as though a spanning tree
> >> algorithm is what is needed here (see Chonn Lee's mail about mesh
> >> networks of DLSw), and that leaves us with having to develop our own
> >> mechanism for preventing this rather specific problem from occuring.
> >> 
> >> The main advantages of this mechanism are:
> >> 
> >> 1.  It doesn't require a change to the SSP portion of DLS.  The only
> >>     change is that the LAN interface portion of DLS must be extended
> >>     to require this protocol.  Note that it localizes the solution to
> >>     just the problem point, rather than distributes it across the
> >>     entire protocol.
> >> 
> >> 2.  It could be optional, if customers are educated about the
> >>     consequences of mis-configuring DLSwitches on the same LAN.
> >> 
> >> The important disadvantages are:
> >> 
> >> 1.  It requires a new LLC SAP.
> >> 
> >> 2.  It is new, and therefore un-tested.
> >>     

> I think it would also need a new multicast address that all DLSw nodes belong
> to.
> 

I was thinking LAN broadcast, but a multicast address would be more efficient.

> >> What do people think?  I would very much like to have something to
> >> propose to the SIG in late September.  The idea presented above may
> >> not be the most elegant solution to the problem, but since no one else
> >> has proposed any solution it may be a good place to start...
> >> 

> Yes, we should try to get a proposal on the table soon. We are running out
> of time...
> 

Yes, indeed.  I'd like to hear what others think about my proposal.
I'm not making any claims that it's a solution handed down from on
high, but at least it's something fairly concrete...

> >> Regards,
> >> Scott
> Regards,
> Choon Lee
> 3Com Corp.

Once again,

Scott